Handle macros with multiple kinds, and improve errors #145153

joshtriplett · 2025-08-09T07:59:24Z

(I recommend reviewing this commit-by-commit.)

Switch to a bitflags MacroKinds to support macros with more than one kind

Review everything that uses MacroKind, and switch anything that could refer to more than one kind to use MacroKinds.

Add a new SyntaxExtensionKind::MacroRules for macro_rules! macros, using the concrete MacroRulesMacroExpander type, and have it track which kinds it can handle. Eliminate the separate optional attr_ext, now that a SyntaxExtension can handle multiple macro kinds.

This also avoids the need to downcast when calling methods on MacroRulesMacroExpander, such as get_unused_rule.

Integrate macro kind checking into name resolution's sub_namespace_match, so that we only find a macro if it's the right type, and eliminate the special-case hack for attributes.

This allows detecting and report macro kind mismatches early, and more precisely, improving various error messages. In particular, this eliminates the case in failed_to_match_macro to check for a function-like invocation of a macro with no function-like rules.

Instead, macro kind mismatches now result in an unresolved macro, and we detect this case in unresolved_macro_suggestions, which now carefully distinguishes between a kind mismatch and other errors.

This also handles cases of forward-referenced attributes and cyclic attributes.

In this PR, I've minimally fixed up rustdoc so that it compiles and passes tests. This is just the minimal necessary fixes to handle the switch to MacroKinds, and it only works for macros that don't actually have multiple kinds. This will panic (with a todo!) if it encounters a macro with multiple kinds.

rustdoc needs further fixes to handle macros with multiple kinds, and to handle attributes and derive macros that aren't proc macros. I'd appreciate some help from a rustdoc expert on that.

r? @petrochenkov

rustbot · 2025-08-09T07:59:30Z

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

rustbot · 2025-08-09T08:37:52Z

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

theemathas · 2025-08-10T03:26:51Z

The cyclic macro from #144579 (comment) still gets a weird diagnostic. The use line is necessary. (use-ing a macro_rules, for reasons I don't quite understand, allows using the macro before it's defined.)

theemathas · 2025-08-10T03:34:53Z

Is it intentional that I can define an attribute macro_rules and a function-like macro_rules, and use both independently?

This code compiles:

#![feature(macro_attr)]

macro_rules! foo {
    attr() { $($x:tt)* } => {};
}

macro_rules! foo {
    () => {};
}

#[foo]
struct Thing;

foo!();

I can even "overwrite" just part of the macro. This code compiles:

#![feature(macro_attr)]

macro_rules! foo {
    attr() { $($x:tt)* } => {};
    () => {
        compile_error!("This arm is not used");
    };
}

macro_rules! foo {
    () => {};
}

#[foo]
struct Thing;

foo!();

joshtriplett · 2025-08-10T05:43:09Z

@theemathas I believe that's expected. What's happening there is shadowing, and shadowing happens independently for each type of macro. A search for an attribute will skip over any fn-like macros, and vice versa.

compiler/rustc_span/src/hygiene.rs

compiler/rustc_lint/src/non_local_def.rs

compiler/rustc_span/src/hygiene.rs

joshtriplett · 2025-08-11T23:23:55Z

I've addressed all the feedback, and rebased to fix the conflict.

@rustbot ready

compiler/rustc_hir/src/lib.rs

joshtriplett · 2025-08-12T16:36:43Z

@bors r=petrochenkov rollup

bors · 2025-08-12T16:36:46Z

📌 Commit e1fc89a has been approved by petrochenkov

It is now in the queue for this repository.

…=petrochenkov Handle macros with multiple kinds, and improve errors (I recommend reviewing this commit-by-commit.) Switch to a bitflags `MacroKinds` to support macros with more than one kind Review everything that uses `MacroKind`, and switch anything that could refer to more than one kind to use `MacroKinds`. Add a new `SyntaxExtensionKind::MacroRules` for `macro_rules!` macros, using the concrete `MacroRulesMacroExpander` type, and have it track which kinds it can handle. Eliminate the separate optional `attr_ext`, now that a `SyntaxExtension` can handle multiple macro kinds. This also avoids the need to downcast when calling methods on `MacroRulesMacroExpander`, such as `get_unused_rule`. Integrate macro kind checking into name resolution's `sub_namespace_match`, so that we only find a macro if it's the right type, and eliminate the special-case hack for attributes. This allows detecting and report macro kind mismatches early, and more precisely, improving various error messages. In particular, this eliminates the case in `failed_to_match_macro` to check for a function-like invocation of a macro with no function-like rules. Instead, macro kind mismatches now result in an unresolved macro, and we detect this case in `unresolved_macro_suggestions`, which now carefully distinguishes between a kind mismatch and other errors. This also handles cases of forward-referenced attributes and cyclic attributes. ---- In this PR, I've minimally fixed up `rustdoc` so that it compiles and passes tests. This is just the minimal necessary fixes to handle the switch to `MacroKinds`, and it only works for macros that don't actually have multiple kinds. This will panic (with a `todo!`) if it encounters a macro with multiple kinds. rustdoc needs further fixes to handle macros with multiple kinds, and to handle attributes and derive macros that aren't proc macros. I'd appreciate some help from a rustdoc expert on that. ---- r? `@petrochenkov`

…=petrochenkov Handle macros with multiple kinds, and improve errors (I recommend reviewing this commit-by-commit.) Switch to a bitflags `MacroKinds` to support macros with more than one kind Review everything that uses `MacroKind`, and switch anything that could refer to more than one kind to use `MacroKinds`. Add a new `SyntaxExtensionKind::MacroRules` for `macro_rules!` macros, using the concrete `MacroRulesMacroExpander` type, and have it track which kinds it can handle. Eliminate the separate optional `attr_ext`, now that a `SyntaxExtension` can handle multiple macro kinds. This also avoids the need to downcast when calling methods on `MacroRulesMacroExpander`, such as `get_unused_rule`. Integrate macro kind checking into name resolution's `sub_namespace_match`, so that we only find a macro if it's the right type, and eliminate the special-case hack for attributes. This allows detecting and report macro kind mismatches early, and more precisely, improving various error messages. In particular, this eliminates the case in `failed_to_match_macro` to check for a function-like invocation of a macro with no function-like rules. Instead, macro kind mismatches now result in an unresolved macro, and we detect this case in `unresolved_macro_suggestions`, which now carefully distinguishes between a kind mismatch and other errors. This also handles cases of forward-referenced attributes and cyclic attributes. ---- In this PR, I've minimally fixed up `rustdoc` so that it compiles and passes tests. This is just the minimal necessary fixes to handle the switch to `MacroKinds`, and it only works for macros that don't actually have multiple kinds. This will panic (with a `todo!`) if it encounters a macro with multiple kinds. rustdoc needs further fixes to handle macros with multiple kinds, and to handle attributes and derive macros that aren't proc macros. I'd appreciate some help from a rustdoc expert on that. ---- r? ``@petrochenkov``

…=petrochenkov Handle macros with multiple kinds, and improve errors (I recommend reviewing this commit-by-commit.) Switch to a bitflags `MacroKinds` to support macros with more than one kind Review everything that uses `MacroKind`, and switch anything that could refer to more than one kind to use `MacroKinds`. Add a new `SyntaxExtensionKind::MacroRules` for `macro_rules!` macros, using the concrete `MacroRulesMacroExpander` type, and have it track which kinds it can handle. Eliminate the separate optional `attr_ext`, now that a `SyntaxExtension` can handle multiple macro kinds. This also avoids the need to downcast when calling methods on `MacroRulesMacroExpander`, such as `get_unused_rule`. Integrate macro kind checking into name resolution's `sub_namespace_match`, so that we only find a macro if it's the right type, and eliminate the special-case hack for attributes. This allows detecting and report macro kind mismatches early, and more precisely, improving various error messages. In particular, this eliminates the case in `failed_to_match_macro` to check for a function-like invocation of a macro with no function-like rules. Instead, macro kind mismatches now result in an unresolved macro, and we detect this case in `unresolved_macro_suggestions`, which now carefully distinguishes between a kind mismatch and other errors. This also handles cases of forward-referenced attributes and cyclic attributes. ---- In this PR, I've minimally fixed up `rustdoc` so that it compiles and passes tests. This is just the minimal necessary fixes to handle the switch to `MacroKinds`, and it only works for macros that don't actually have multiple kinds. This will panic (with a `todo!`) if it encounters a macro with multiple kinds. rustdoc needs further fixes to handle macros with multiple kinds, and to handle attributes and derive macros that aren't proc macros. I'd appreciate some help from a rustdoc expert on that. ---- r? ```@petrochenkov```

Rollup of 7 pull requests Successful merges: - #144642 (editorconfig: don't trim trailing whitespace in tests) - #144955 (search graph: lazily update parent goals) - #145153 (Handle macros with multiple kinds, and improve errors) - #145250 (Add regression test for former ICE involving malformed meta items containing interpolated tokens) - #145269 (Deprecate RUST_TEST_* env variables) - #145289 (chore(ci): upgrade checkout to v5) - #145303 (Docs: Link to payload_as_str() from payload().) r? `@ghost` `@rustbot` modify labels: rollup

…=petrochenkov Handle macros with multiple kinds, and improve errors (I recommend reviewing this commit-by-commit.) Switch to a bitflags `MacroKinds` to support macros with more than one kind Review everything that uses `MacroKind`, and switch anything that could refer to more than one kind to use `MacroKinds`. Add a new `SyntaxExtensionKind::MacroRules` for `macro_rules!` macros, using the concrete `MacroRulesMacroExpander` type, and have it track which kinds it can handle. Eliminate the separate optional `attr_ext`, now that a `SyntaxExtension` can handle multiple macro kinds. This also avoids the need to downcast when calling methods on `MacroRulesMacroExpander`, such as `get_unused_rule`. Integrate macro kind checking into name resolution's `sub_namespace_match`, so that we only find a macro if it's the right type, and eliminate the special-case hack for attributes. This allows detecting and report macro kind mismatches early, and more precisely, improving various error messages. In particular, this eliminates the case in `failed_to_match_macro` to check for a function-like invocation of a macro with no function-like rules. Instead, macro kind mismatches now result in an unresolved macro, and we detect this case in `unresolved_macro_suggestions`, which now carefully distinguishes between a kind mismatch and other errors. This also handles cases of forward-referenced attributes and cyclic attributes. ---- In this PR, I've minimally fixed up `rustdoc` so that it compiles and passes tests. This is just the minimal necessary fixes to handle the switch to `MacroKinds`, and it only works for macros that don't actually have multiple kinds. This will panic (with a `todo!`) if it encounters a macro with multiple kinds. rustdoc needs further fixes to handle macros with multiple kinds, and to handle attributes and derive macros that aren't proc macros. I'd appreciate some help from a rustdoc expert on that. ---- r? ````@petrochenkov````

…=petrochenkov Handle macros with multiple kinds, and improve errors (I recommend reviewing this commit-by-commit.) Switch to a bitflags `MacroKinds` to support macros with more than one kind Review everything that uses `MacroKind`, and switch anything that could refer to more than one kind to use `MacroKinds`. Add a new `SyntaxExtensionKind::MacroRules` for `macro_rules!` macros, using the concrete `MacroRulesMacroExpander` type, and have it track which kinds it can handle. Eliminate the separate optional `attr_ext`, now that a `SyntaxExtension` can handle multiple macro kinds. This also avoids the need to downcast when calling methods on `MacroRulesMacroExpander`, such as `get_unused_rule`. Integrate macro kind checking into name resolution's `sub_namespace_match`, so that we only find a macro if it's the right type, and eliminate the special-case hack for attributes. This allows detecting and report macro kind mismatches early, and more precisely, improving various error messages. In particular, this eliminates the case in `failed_to_match_macro` to check for a function-like invocation of a macro with no function-like rules. Instead, macro kind mismatches now result in an unresolved macro, and we detect this case in `unresolved_macro_suggestions`, which now carefully distinguishes between a kind mismatch and other errors. This also handles cases of forward-referenced attributes and cyclic attributes. ---- In this PR, I've minimally fixed up `rustdoc` so that it compiles and passes tests. This is just the minimal necessary fixes to handle the switch to `MacroKinds`, and it only works for macros that don't actually have multiple kinds. This will panic (with a `todo!`) if it encounters a macro with multiple kinds. rustdoc needs further fixes to handle macros with multiple kinds, and to handle attributes and derive macros that aren't proc macros. I'd appreciate some help from a rustdoc expert on that. ---- r? `````@petrochenkov`````

Rollup of 9 pull requests Successful merges: - #122661 (Change the desugaring of `assert!` for better error output) - #138736 (Sanitizers target modificators) - #144955 (search graph: lazily update parent goals) - #145120 (llvm: Accept new LLVM lifetime format) - #145153 (Handle macros with multiple kinds, and improve errors) - #145189 (Weekly `cargo update`) - #145250 (Add regression test for former ICE involving malformed meta items containing interpolated tokens) - #145309 (Fix `-Zregparm` for LLVM builtins) - #145331 (Make std use the edition 2024 prelude) r? `@ghost` `@rustbot` modify labels: rollup

…=petrochenkov Handle macros with multiple kinds, and improve errors (I recommend reviewing this commit-by-commit.) Switch to a bitflags `MacroKinds` to support macros with more than one kind Review everything that uses `MacroKind`, and switch anything that could refer to more than one kind to use `MacroKinds`. Add a new `SyntaxExtensionKind::MacroRules` for `macro_rules!` macros, using the concrete `MacroRulesMacroExpander` type, and have it track which kinds it can handle. Eliminate the separate optional `attr_ext`, now that a `SyntaxExtension` can handle multiple macro kinds. This also avoids the need to downcast when calling methods on `MacroRulesMacroExpander`, such as `get_unused_rule`. Integrate macro kind checking into name resolution's `sub_namespace_match`, so that we only find a macro if it's the right type, and eliminate the special-case hack for attributes. This allows detecting and report macro kind mismatches early, and more precisely, improving various error messages. In particular, this eliminates the case in `failed_to_match_macro` to check for a function-like invocation of a macro with no function-like rules. Instead, macro kind mismatches now result in an unresolved macro, and we detect this case in `unresolved_macro_suggestions`, which now carefully distinguishes between a kind mismatch and other errors. This also handles cases of forward-referenced attributes and cyclic attributes. ---- In this PR, I've minimally fixed up `rustdoc` so that it compiles and passes tests. This is just the minimal necessary fixes to handle the switch to `MacroKinds`, and it only works for macros that don't actually have multiple kinds. This will panic (with a `todo!`) if it encounters a macro with multiple kinds. rustdoc needs further fixes to handle macros with multiple kinds, and to handle attributes and derive macros that aren't proc macros. I'd appreciate some help from a rustdoc expert on that. ---- r? ``````@petrochenkov``````

…=petrochenkov Handle macros with multiple kinds, and improve errors (I recommend reviewing this commit-by-commit.) Switch to a bitflags `MacroKinds` to support macros with more than one kind Review everything that uses `MacroKind`, and switch anything that could refer to more than one kind to use `MacroKinds`. Add a new `SyntaxExtensionKind::MacroRules` for `macro_rules!` macros, using the concrete `MacroRulesMacroExpander` type, and have it track which kinds it can handle. Eliminate the separate optional `attr_ext`, now that a `SyntaxExtension` can handle multiple macro kinds. This also avoids the need to downcast when calling methods on `MacroRulesMacroExpander`, such as `get_unused_rule`. Integrate macro kind checking into name resolution's `sub_namespace_match`, so that we only find a macro if it's the right type, and eliminate the special-case hack for attributes. This allows detecting and report macro kind mismatches early, and more precisely, improving various error messages. In particular, this eliminates the case in `failed_to_match_macro` to check for a function-like invocation of a macro with no function-like rules. Instead, macro kind mismatches now result in an unresolved macro, and we detect this case in `unresolved_macro_suggestions`, which now carefully distinguishes between a kind mismatch and other errors. This also handles cases of forward-referenced attributes and cyclic attributes. ---- In this PR, I've minimally fixed up `rustdoc` so that it compiles and passes tests. This is just the minimal necessary fixes to handle the switch to `MacroKinds`, and it only works for macros that don't actually have multiple kinds. This will panic (with a `todo!`) if it encounters a macro with multiple kinds. rustdoc needs further fixes to handle macros with multiple kinds, and to handle attributes and derive macros that aren't proc macros. I'd appreciate some help from a rustdoc expert on that. ---- r? ```````@petrochenkov```````

Rollup of 9 pull requests Successful merges: - #144761 (aarch64: Make `outline-atomics` a known target feature) - #144949 (More `Printer` cleanups) - #144955 (search graph: lazily update parent goals) - #144962 (Add aarch64_be-unknown-none-softfloat target) - #145153 (Handle macros with multiple kinds, and improve errors) - #145241 ([AVR] Changed data_layout) - #145341 (Install libgccjit into the compiler's sysroot when cg_gcc is enabled) - #145349 (Correctly handle when there are no unstable items in the documented crate) - #145356 (Add another example for escaped `#` character in doctest in rustdoc book) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #145153 - joshtriplett:macro-kinds-plural, r=petrochenkov Handle macros with multiple kinds, and improve errors (I recommend reviewing this commit-by-commit.) Switch to a bitflags `MacroKinds` to support macros with more than one kind Review everything that uses `MacroKind`, and switch anything that could refer to more than one kind to use `MacroKinds`. Add a new `SyntaxExtensionKind::MacroRules` for `macro_rules!` macros, using the concrete `MacroRulesMacroExpander` type, and have it track which kinds it can handle. Eliminate the separate optional `attr_ext`, now that a `SyntaxExtension` can handle multiple macro kinds. This also avoids the need to downcast when calling methods on `MacroRulesMacroExpander`, such as `get_unused_rule`. Integrate macro kind checking into name resolution's `sub_namespace_match`, so that we only find a macro if it's the right type, and eliminate the special-case hack for attributes. This allows detecting and report macro kind mismatches early, and more precisely, improving various error messages. In particular, this eliminates the case in `failed_to_match_macro` to check for a function-like invocation of a macro with no function-like rules. Instead, macro kind mismatches now result in an unresolved macro, and we detect this case in `unresolved_macro_suggestions`, which now carefully distinguishes between a kind mismatch and other errors. This also handles cases of forward-referenced attributes and cyclic attributes. ---- In this PR, I've minimally fixed up `rustdoc` so that it compiles and passes tests. This is just the minimal necessary fixes to handle the switch to `MacroKinds`, and it only works for macros that don't actually have multiple kinds. This will panic (with a `todo!`) if it encounters a macro with multiple kinds. rustdoc needs further fixes to handle macros with multiple kinds, and to handle attributes and derive macros that aren't proc macros. I'd appreciate some help from a rustdoc expert on that. ---- r? ````````@petrochenkov````````

Kobzol · 2025-08-14T08:13:58Z

@rust-timer build c3f8df3

Testing for #145366.

rust-timer · 2025-08-14T12:10:58Z

Finished benchmarking commit (c3f8df3): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.1%, 1.4%]	37
Regressions ❌ (secondary)	0.3%	[0.2%, 0.6%]	20
Improvements ✅ (primary)	-0.8%	[-3.4%, -0.2%]	6
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[-3.4%, 1.4%]	43

Max RSS (memory usage)

Results (secondary 4.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.6%	[4.6%, 4.6%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

Results (primary -0.8%, secondary -5.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.8%	[1.8%, 1.8%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.4%	[-3.4%, -3.4%]	1
Improvements ✅ (secondary)	-5.0%	[-5.0%, -5.0%]	1
All ❌✅ (primary)	-0.8%	[-3.4%, 1.8%]	2

Binary size

Results (primary -0.2%, secondary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.0%	[0.0%, 0.0%]	2
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	3
Improvements ✅ (primary)	-0.3%	[-0.8%, -0.1%]	4
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	2
All ❌✅ (primary)	-0.2%	[-0.8%, 0.0%]	6

Bootstrap: 467.825s -> 470.343s (0.54%)
Artifact size: 377.36 MiB -> 377.34 MiB (-0.00%)

rustbot assigned petrochenkov Aug 9, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Aug 9, 2025

This comment was marked as outdated.

Sign in to view

rustbot added the T-clippy Relevant to the Clippy team. label Aug 9, 2025

This comment was marked as outdated.

Sign in to view

joshtriplett force-pushed the macro-kinds-plural branch from 1854363 to 2d1b77e Compare August 9, 2025 08:52

This was referenced Aug 10, 2025

Implement declarative (macro_rules!) attribute macros (RFC 3697) #144579

Merged

Implement declarative (macro_rules!) derive macros (RFC 3698) #145208

Draft

This comment was marked as resolved.

Sign in to view

petrochenkov reviewed Aug 11, 2025

View reviewed changes

compiler/rustc_span/src/hygiene.rs Outdated Show resolved Hide resolved

compiler/rustc_lint/src/non_local_def.rs Outdated Show resolved Hide resolved

petrochenkov reviewed Aug 11, 2025

View reviewed changes

compiler/rustc_span/src/hygiene.rs Outdated Show resolved Hide resolved

petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 11, 2025

joshtriplett force-pushed the macro-kinds-plural branch 2 times, most recently from bb755c2 to a076257 Compare August 11, 2025 23:23

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 11, 2025

This comment was marked as outdated.

Sign in to view

joshtriplett force-pushed the macro-kinds-plural branch from a076257 to 861b36e Compare August 11, 2025 23:37

This comment was marked as outdated.

Sign in to view

joshtriplett force-pushed the macro-kinds-plural branch from 861b36e to 76b99cc Compare August 11, 2025 23:54

petrochenkov reviewed Aug 12, 2025

View reviewed changes

compiler/rustc_hir/src/lib.rs Outdated Show resolved Hide resolved

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 12, 2025

jhpratt mentioned this pull request Aug 12, 2025

Rollup of 8 pull requests #145317

Closed

jhpratt mentioned this pull request Aug 12, 2025

Rollup of 7 pull requests #145319

Closed

Zalathar mentioned this pull request Aug 13, 2025

Rollup of 10 pull requests #145346

Closed

jdonszelmann mentioned this pull request Aug 13, 2025

Rollup of 9 pull requests #145351

Closed

GuillaumeGomez mentioned this pull request Aug 13, 2025

Rollup of 11 pull requests #145363

Closed

This was referenced Aug 13, 2025

Rollup of 11 pull requests #145365

Closed

Rollup of 9 pull requests #145366

Merged

bors merged commit bd6fb63 into rust-lang:master Aug 13, 2025
10 checks passed

rustbot added this to the 1.91.0 milestone Aug 13, 2025

joshtriplett deleted the macro-kinds-plural branch August 14, 2025 01:52

This comment has been minimized.

Sign in to view

rustbot added the perf-regression Performance regression. label Aug 14, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Handle macros with multiple kinds, and improve errors #145153

Handle macros with multiple kinds, and improve errors #145153

joshtriplett commented Aug 9, 2025

Uh oh!

rustbot commented Aug 9, 2025

Uh oh!

This comment was marked as outdated.

rustbot commented Aug 9, 2025

Uh oh!

This comment was marked as outdated.

theemathas commented Aug 10, 2025

Uh oh!

theemathas commented Aug 10, 2025 •

edited

Loading

Uh oh!

joshtriplett commented Aug 10, 2025

Uh oh!

This comment was marked as resolved.

Uh oh!

Uh oh!

Uh oh!

joshtriplett commented Aug 11, 2025

Uh oh!

This comment was marked as outdated.

This comment was marked as outdated.

Uh oh!

joshtriplett commented Aug 12, 2025

Uh oh!

bors commented Aug 12, 2025

Uh oh!

Uh oh!

Kobzol commented Aug 14, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Aug 14, 2025

Uh oh!

Uh oh!

Handle macros with multiple kinds, and improve errors #145153

Handle macros with multiple kinds, and improve errors #145153

Conversation

joshtriplett commented Aug 9, 2025

Uh oh!

rustbot commented Aug 9, 2025

Uh oh!

This comment was marked as outdated.

rustbot commented Aug 9, 2025

Uh oh!

This comment was marked as outdated.

theemathas commented Aug 10, 2025

Uh oh!

theemathas commented Aug 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

joshtriplett commented Aug 10, 2025

Uh oh!

This comment was marked as resolved.

Uh oh!

Uh oh!

Uh oh!

joshtriplett commented Aug 11, 2025

Uh oh!

This comment was marked as outdated.

This comment was marked as outdated.

Uh oh!

joshtriplett commented Aug 12, 2025

Uh oh!

bors commented Aug 12, 2025

Uh oh!

Uh oh!

Kobzol commented Aug 14, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Aug 14, 2025

Overall result: ❌✅ regressions and improvements - please read the text below

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Uh oh!

theemathas commented Aug 10, 2025 •

edited

Loading